The present invention relates generally to creating or developing computer programs, and more specifically, to systems and methods for determining the complexity of a computer program with a view to ensuring code quality.
As computer programs expand in size and complexity, the need to assess the reliability of software becomes more important so that appropriate corrective action can be taken prior to releasing the software. Assuring the reliability of software helps to minimize software development costs, reduces support costs, improve software quality, increase programmer productivity, and shorten software development time. By controlling the quality and reliability of a program, more precise, predictable and repeatable control can be had over software development process and product. Complexity measurement algorithms are used to analyze code of computer programs to determine the complexity and predict the reliability of the computer programs. Program complexity is an important measurement since an increase in program complexity has been shown to result in a decrease in reliability and an increase in program errors and support costs. Moreover, the more complex a program is, the more difficult it is to debug or modify, since a higher amount of concentration is required to understand the program.
The complexity of a program can be measured by a number of different metrics. One popular numeric technique for measuring complexity is the McCabe cyclomatic complexity metric which is described in A Complexity Measure, IEEE Transactions on Software Engineering, Volume 2, No. 4 (December 1976), pp. 308-320, by Tom McCabe, which is incorporated herein by reference in its entirety. McCabe measures complexity by counting the number of decision points in a computer routine. For example, a straight path through the routine counts as one. One is then added for each of the following keywords, or their equivalents (depending on which programming language is used): if, while, repeat, for, and, or. A case statement results in addition of another one. After counting the decision points, the total is used to analyze the complexity of the routine. For example, if the total is between one and five the reliability of the routine is probably acceptable. Ideally, if the total is between six and ten, the programmer should start to think about ways to simplify the routine. The routine should be broken into smaller subroutines or modified if the total is above ten. Additional metrics could include date related software metrics, object oriented software metrics, and line count software metrics. Other complexity measurements include the amount of data used, the number of variables used in a subroutine, the number of nesting levels in control constructs, the number of lines of code, the number of lines between successive references to variables, and the number of input and output values.
The complexity of a program is typically checked after the program is completed. The finished program may be run through a program which analyzes the complete computer program and provides a breakdown of complexity metrics for the subroutines. A problem with this type of measurement is that it is difficult to revise the program to reduce the complexity after the entire program has been written. In order to reduce the complexity factor, entire subroutines or a major part of the program may have to be rewritten, thus requiring a significant amount of reprogramming time.
There is, therefore, a need for a system and method for measuring the complexity of computer programs while the program is being entered into a computer system and providing a programmer with up to date complexity statistics of the program so that the programmer can make changes to the program while it is being created.
A system and method for determining complexity of a computer subroutine during development of the subroutine is disclosed.
A method for determining the complexity factor includes analyzing a plurality of statements of the subroutine and computing a complexity factor for a completed portion of the subroutine. The steps of analyzing the subroutine and computing a complexity factor are repeated following input of another statement into the subroutine.
A system for determining the complexity factor includes an analyzer operable to analyze the statements and produce a complexity factor following the input of one of the plurality of statements into the subroutine.
In one embodiment, the system includes a notification system operable to notify a user of the system when the complexity factor of the subroutine exceeds a maximum value. The notification system may provide a visual notification, an audio notification, or both. The notification system may also notify the user of the computed complexity factor.
The above is a brief description of some deficiencies in the prior art and advantages of the present invention. Other features, advantages, and embodiments of the invention will be apparent to those skilled in the art from the following description, drawings, and claims.